Review:(Wentzlaff, Agarwal, 2009)
Factored Operating Systems (fos): The Case for a Scalable Operating System for Multicores Reference: (Wentzlaff, Agarwal, 2009) Abstract The next decade will afford us computer chips with 100’s to 1,000’s of cores on a single piece of silicon. Contemporary operating systems have been designed to operate on a single core or small number of cores and hence are not well suited to manage and provide operating system services at such large scale. If multicore trends continue, the number of cores that an operating system will be managing will continue to double every 18 months. The traditional evolutionary approach of redesigning OS subsystems when there is insufficient parallelism will cease to work because the rate of increasing parallelism will far outpace the rate at which OS designers will be capable of redesigning subsystems. The fundamental design of operating systems and operating system data structures must be rethought to put scalability as the prime design constraint. This work begins by documenting the scalability problems of contemporary operating systems. These studies are used to motivate the design of a factored operating system (fos). fos is a new operating system targeting many core systems with scalability as the primary design constraint, where space sharing replaces time sharing to increase scalability. We describe fos, which is built in a message passing manner, out of a collection of Internet inspired services. Each operating system service is factored into a set of communicating servers which in aggregate implement a system service. These servers are designed much in the way that distributed Internet services are designed, but instead of providing high level Internet services, these servers provide traditional kernel services and replace traditional kernel data structures in a factored, spatially distributed manner. fos replaces time sharing with space sharing. In other words, fos’s servers are bound to distinct processing cores and by doing so do not fight with end user applications for implicit resources such as TLBs and caches. We describe how fos’s design is well suited to attack the scalability challenge of future multicores and discuss how traditional application-operating systems interfaces can be redesigned to improve scalability. Notes This paper is very significant in the context of a COS. 2.4 Recommendations The problems presented in this section 2 lead to a few recommendations in order to improve scalability for future operating systems, namely: * Avoid the use of hardware locks. * Separate the operating system execution resources from the application execution resources. ** Reduces implicit resource sharing (Caches/TLBs). ** Utilizes the ample thread parallelism provided by multicore processors. * Avoid global cache coherent shared memory ** Broadens applicability to architectures which don’t support shared memory. ** Shared memory hardware may not scale to large core count. 3.1 Design Principles In order to achieve the goal of scaling over multiple orders of magnitude in core count, fos utilizes the following design principles: * Space multiplexing replaces time multiplexing. ** Scheduling becomes a layout problem not a time multiplexing problem. ** OS runs on distinct cores from applications. ** Working sets are spatially partitioned; OS does not interfere with applications cache. * OS is factored into function specific services. ** Each OS service is distributed into spatially distributed servers. ** Servers collaborate and communicate only via message passing. ** Servers are bound to a core. ** Applications communicate with servers via message passing. ** Servers leverage ideas (caching, replication, spatial distribution, lazy update) from Internet servers. Comments * In AOS 1 there is no time multiplexing, each process runs on its own processor to completion. * In a COS, having the OS on separate cores is intrinsic to the design. * OS does not interfere with the Application processors, other than to configure networks of processors. * The whole of a COS at it most abstract level assumes a message pssing architecture. Category:Review